Binding agreements are at the core of all commercial and societal transactions. Individuals, government and business entities increasingly rely on the accessibility, speed and other advantages of computer based communications to facilitate such business transactions. As with any agreement, a party is legally bound to obligations undertaken in a transaction when proof evidences that the party agreed to, validated or otherwise affirmed the transaction. Similarly, that party can be held accountable for the truth of a statement or the consequences of a sanctioned act where proof shows the party condoned or affirmed the activity or statement. The nature of computer transactions, however, does not involve the face-to-face interaction between agreeing parties conventionally used to sign or otherwise consummate such agreements.
Institutions have consequently developed practices useful in authenticating non-face-to-face computer transactions. For instance, electronic signatures are used in connection with electronic messages to provide a way for the sender of a message to electronically “sign” the message. The electronic signature functions similarly to a conventional signature in that it provides proof of the identify of the sender and can validate a sender's acknowledgment of the content of the message.
More particularly, an electronic signature may include an electronic sound, symbol or process attached to or logically associated with a contract or other record. The record is executed or adopted when a person signs the record. This signing may be accomplished using a signature comprising a password, token, digitized image, knowledge based authentication and/or a biometric record. An electronic signature thus includes any electronic identifier created by a computer and intended by a party using is to have the same force and effect as a manual signature.
Electronic signatures typically use an asymmetric cryptosystem to ensure document integrity, security and authenticity of an electronic document. Namely, a sender digitally signs the message using a private key. The key includes encryption software used to create a digital signature. The receiver validates the sender's digital signature using a public key of the sender. The public key includes software sent by the receiver used to decrypt the digital signature on the document. Exemplary documents may include any record that is generated or stored on a computer, such as a letter, a tax form, a contract, or a will. In addition, an electronic document may include an image, such as a blueprint, a survey plat, a drawing, or even a photograph. An electronic signature may be used to sign these documents types.
While electronic signatures provide assurances as to the intention and identity of the sender, the underlying programming associated with electronic signature practices can limit their application in the context of certain types of transactions. For instance, a different program template must generally be created for each transaction that involves a new agreement format. That is, the program code used to place a digital signature on a given form must be manually modified or replaced in order to execute a similar signature on another agreement.
Each unique form for a particular transaction and of a particular lender often requires an electronic signature at a particular point that is unique to that form. For instance, even a relatively generic lending form may require placement of the electronic signature at slightly different relative coordinates. Though such differences may be largely imperceptible to a loan applicant, the subtle differences nonetheless require unique programming and configuration of the electronic signature program to ensure proper placement of the electronic signature at the different relative document position. Put another way, even minor differences in the forms will require different programmatic instructions. Such instructions dictate where and how a signature must be accomplished within the new or altered document.
This requirement to create a new program profile is a potential source of inefficiency and substantial expenditures for certain businesses. For instance, many commercial lending operations involve hundreds of proprietary forms. Each form requires its own programming template to be accomplished. Moreover, each form may be altered over time in accordance with government regulations and client requirements. As such, each form can require additional programming. As a consequence, lenders must wait for a programmer to manually set up required programming so that a transaction can proceed. Such program requirements can unduly delay the execution of electronic signatures, holding up time sensitive transactions or altogether obviating their practicality. Such requirements further undermine the speed and automation that generally benefit electronic loan processing. Moreover, existing systems do not support boolean (checkbox) output text, or “prior approval” practices endemic to many financial transactions. There is also no systematic way of knowing with certainty that a user is actually able to view digitized form.
The inflexible nature of conventional electronic signature practices further requires a loan officer or programmer to manually and individually identify each document so that it can be properly matched to its appropriate signing algorithm template. In the context of hundreds or thousands of documents, this manual submission represents an additional source of inefficiency. Furthermore, certain types of documents must be timely executed in a particular sequence and/or by multiple signatories. Conventional electronic signing programs provide no mechanism that ensures that multiple signatures are accomplished, or that they are executed in a required sequence.
Consequently, and for in part the above delineated reasons, there exists a need for an improved manner of managing an electronic document signing process.